初歩的な質問で申し訳ございません。
　掲題の件、友人から質問を受けております。お手数ではありますが、ご教授頂きたいと思います。

MIDIって楽器のシーケンサフォーマットのですよね？
この場合、MIDIからMPEG-1 Layer3 Audioへの変換かな?
映像とは関係ないので、音声編集ソフトをあたりましょう。

　もう少しわかりやすく説明すると、こんかい質問のあった
MIDIは楽譜をそのままファイルにしたものです。
MPEGはビデオで録画された映像や録音された生音を効率よくDVDやCDなどのメディアに記録したものです。
貴方の質問は「ここに楽譜があるんだけどこれをCDにして聞くことができないでしょうか？」
というものになります。ですから楽譜を演奏してくれるオーケストラ（いわゆるMIDI対応の音源と演奏ソフト）とそれを録音してCDにしてくれる音響スタジオ（録音できるソフトとそれをMPEGにするエンコーダー）が必要なのです。この作業をするのはこちらのソフトでは無理だと言うことになります。

midiからmp3に変換する方法。
まずmidiファイルをメディアプレイヤーで開く。
次にウィンドウズに付いているCreative MediaSource プレイヤーを開く。
Jet-Audio Playerとも呼んでいるものだ。
そこに録音できるところがあるからこれを出力wmaかwavに設定する。
ウィンドウズメディアプレイヤーで鳴らす。それを録音する。
それをRip!AudiCO FREEとい無料のソフトでmp3に変換する。
録音の長さなどの切り貼りを無料のmp3cut2cctというソフトで仕上げることもできる。

標準のWindowsには
>Creative MediaSource
>Jet-Audio Player
は搭載されていません。
サウンドブラスター系のサウンドカードに付属していたのではないでしょうか？

ＡＶＩファイルからＭＰＥＧ２へエンコードしようと出力開始を始めると、
「ディスクに十分な空き容量がありません」とエラーになってしまいます。
出力先の外付けＨＤＤは１７ＧＢくらいの空きがあり容量には問題ないのですが
「４．１ＧＢの空き容量が必要です」となってしまいます。
Ｃドライブで試したところ出力できました。何故でしょうか？

また速度優先にしてましたがエンコード完了まで１６時間もかかりました。
速度優先にした以外はデフォルト設定で行いましたが
何か設定がおかしかったのでしょうか？
よろしくお願い致します。

ハードディスクが「FAT32」というフォーマットになっていると4G以上のファイルの作成は
どんなソフトでも無理です。
「NTFS」というフォーマットに変換するか、再フォーマットを行ってください。

> また速度優先にしてましたがエンコード完了まで１６時間もかかりました。

16時間の時間がおかしいかどうかは、エンコード元のソースの長さ(時間)とあなたの
PC環境によって変わります。30分程度のソースで最新のPentium4環境(3GHz以上)なら、
16時間掛かるのはおかしいと思いますが、もっと長いソースでもっと遅いPCを使って
いるなら、16時間程度掛かるということも十分に考えられます。

ちょうきさん、fayさん、ありがとうございます。

４Ｇ制限はフォーマットのせいだったんですね、
出力先をＣドライブにしたらできました。

CPUはceleron 2G でソースは約２時間でしたが１６時間は普通でしょうか？

>CPUはceleron 2G でソースは約２時間でしたが１６時間は普通でしょうか？

Celeron 1.3Gマシンを使っていたことがあります。
2時間のDV-AVIファイルをMPEG2にエンコードするのに掛かった時間は、記憶に
よれば以下の通りです。

フィルター無しの2Pass VBRで丸1日弱。（約18時間）
フィルターアリの2Pass VBRで3〜4日。（約50時間）

一晩で終わらないのが嫌になり、Enc専用にPen4/2.4GHzマシンを組みました。
入力ソースがDivX等の重いコーデックだと、もっと時間が掛かるでしょう。
うちはMPEG2→MPEG2か、DV→MPEG2しかやらないので良く判りませんが。

TMPGEnc 3.0 XPress 3.1.2.66に専用 DivX Pro Plug-inを入れてます。
専用 DivX Pro Plug-inを入れる前にもDIGAで録り貯めた映画等をDivX
にしてましたが、しばらくＰＣの熱暴走が怖くて休んでいる間に専用
DivX Pro Plug-inが発売になったので入れて先週末からまたDivXにす
る作業を再開しました。DivX 5.2.1で専用 DivX Pro Plug-inは1.0.1.34
にしてます。

未だに映像部分の最適な設定が分からずに模索してるんですが、出来
る限り仕上がりファイルサイズを押さえる為に音声は48KHz、ステレオ、
48kbsにしてます。以前はこの設定でも特に問題なかったのですが、今
回専用 DivX Pro Plug-inを入れた事で確かMP3エンコーダも変わったと
思いました。このエンコーダの癖なのか同じ設定にすると高周波なノ
イズが入ります。キリキリ音というか３本違う映画で試しましたがどれ
もノイズが入ります。これは設定の問題なのか新しいMP3のエンコーダの
問題なのかが分かりませんが、こちらだけの現象でしょうか？
#Advanced Acoustic Engine MP3 エンコーダって奴ですね＾＾；

既に映像でも何度か試してるんですが、結局素人な自分にはDivX Pro
にした恩恵は全く無く全てデフォルト設定がパフォーマンス的にもあ
っている感じがしました。マルチパスやノイズ除去等は結局エンコ時
間が長い割りに違いが今一分かりませんでした＾＾； このままでは、
専用 DivX Pro Plug-in分全てが無駄になりそうです。せめてMP3エン
コーダのメリットはあればいいのですが、デメリットでは最悪です(T_T)
試しに48kbsではなく96kbsとかでも試しました。96kbsではノイズは
ありませんでした。レートを落とすトレードオフとしてノイズが入る
ってのは以前利用していたMP3エンコーダでは無かった訳なので、これ
が不具合なのか、仕様上諦めるべきのもなのかの回答頂ければ幸いです。

一般的にフラウンフォーファー製MP3エンコーダー（Windowsについてるやつ）はMP3の特許を持つ会社の
特権のようなもので、異常に低ビットレートに強い仕様で有るようです。
公開され、MP3の規格とされている以上の仕組みを取り入れているらしいので、他社製は低ビットレート域では
なかなか音質勝負は難しいようです。

LAMEなどのフリーのエンコーダーと同じくペガシスのMP3も高音質派のようで44khz128kbpsなどの
一般的なMP3設定以上の設定で高音質を発揮するようです。

一般的に高サンプリングレート低ビットレートという設定は行いません。
高サンプリングレートでは必要な情報が多すぎる為、一定以下のビットレートでは再現できません。
フラウンフォーファー製の物では自動的に音を思いっきり削るので実際には48khzの設定の意味をなしていません。
これをせずに実直に再現しようとすると破綻が置き易くなる、と言うことです。
こういう場合はサンプリングレートを下げるのが一般的で、よく使われるのが24Khz56kbps
と言った設定ですね。

またDivXはエンコード時の設定も重要ですがデコード設定（再生時）の設定で画質をおとして
スムーズに再生する　といったモードがONになっている事が多いのでその辺を確認するのも良いかもです。

一般的に、MP3のエンコードではサンプリングレート毎にビットレートの実用の下限が
あると考えます。
私の主観で言うなら、48KHzは128kbps程度、32KHzで96kbps程度、24KHzで56kbps程度が
実用の下限だと思います。これを下回る場合は音質を諦めて聞ければよいと割り切るか、
モノラルにしてしまいます。

ちょうきさん、fayさん、コメントありがとうございます。

お二人とも凄く参考になりました。音質にはあまり拘ってませんので
24KHz 56kbsで試してみます。

>またDivXはエンコード時の設定も重要ですがデコード設定（再生時）の設定で画質をおとして
>スムーズに再生する　といったモードがONになっている事が多いのでその辺を確認するのも良いかもです。

この点もチェックしてみますm(__)m

すみません。TMPGEncをはじめて使うのですが、
色々ページを見てもわからないかったので
質問させてください。

avi→mpeg2へ変換をしているのですが
見積もりで40時間とか平気で越えてしまう状態です。
なるべく質を落とさず、短くする方法や
一時変換をやめて、後日またそこから変換を始められたりもするのでしょうか？

初心者でもわかるWEBページがありましたら
教えてください

よろしくお願いいたします。

検索：エンコード時間
http://bbs.pegasys-inc.com/bbscgi/search/namazu.cgi?query=%A5%A8%A5%F3%A5%B3%A1%BC%A5%C9%BB%FE%B4%D6&whence=0&lang=ja&max=20&result=normal&sort=score&idxname=ja%2Fte30

検索：一時停止
http://bbs.pegasys-inc.com/bbscgi/search/namazu.cgi?query=%B0%EC%BB%FE%C4%E4%BB%DF&whence=0&lang=ja&max=20&result=normal&sort=score&idxname=ja%2Fte30

検索：中断
http://bbs.pegasys-inc.com/bbscgi/search/namazu.cgi?query=%C3%E6%C3%C7&whence=0&lang=ja&max=20&result=normal&sort=score&idxname=ja%2Fte30

検索：再開
http://bbs.pegasys-inc.com/bbscgi/search/namazu.cgi?query=%BA%C6%B3%AB&whence=0&lang=ja&max=20&result=normal&sort=score&idxname=ja%2Fte30

Google：TMPGEnc 使い方
http://www.google.com/search?hl=ja&ie=S-JIS&oe=S-JIS=1&q=TMPGEnc%20使い方&lr=lang_ja

検索機能を使うと良いでしょう。

TMPGEnc MPEG Editorのバッチエンコードツールのオプション→環境設定内に、
「同時出力バッチ処理数」という設定があります。

今使用しているPCはHTなのでこれを「2」に設定出来るのですが、単純にDVD-VIDEOをHDDに取り込みMPEG2へ無劣化出力する際に効果はあるのでしょうか？

たしかに一応2個の出力を平行して実行しているようですが、1個あたりの速度は明らかに落ちているようですし・・・。

効果があるかどうかということなら、物理的にCPUが２つ以上搭載されている環境である
なら効果はあります。HTでは効果がほとんどないでしょう。

ただマルチCPU環境だったとしてもTMPGEnc 3.0 XPressよりもエンコードする機会が
少ないMPEG Editorでは、効果が高いとはいえないでしょう。スマートレンダリングは
CPUよりもHDDの速度がモノを言うからです。

TMPGEnc初心者のイーグルパークです。

「TMPGEnc Plus v2.59」で、まるも製作所の「MPEG-2 VIDEO VFAPI Plug-In」を使ってみた
のですが、やはりキャプチャーしたMPG-2ファイル720-480(IODATA GV-MVP/RZ)は読めません
でした。そこで、今日「TMPGEnc 3.0 XPress」を入手してやってみたら、すぐに読み込めました。

この XPressについての質問ですが、以前にキャプチャーしたMPG-1ファイルなどの
カット編集する場合、出力設定でフォーマット(サイズやビットレイト)を、その都度
設定しなければならないのでしょうか？

それとも、『映像ソース』のフォーマットをそのまま適用する方法があるのでしょうか？
「TMPGEnc Plus 2.5」の場合は、入力の形式がそのまま適用されていたような気がします
が・・・。(違っていたらすみません)

よろしくお願い致します。

>「TMPGEnc Plus v2.59」で、まるも製作所の「MPEG-2 VIDEO VFAPI Plug-In」を使ってみた

TMPGEnc Plusの最新版はv2.521で、XPRESSと同様にCRIのMPEGデコーダが搭載されました。Plusのライセンスを持っているのならば、無料でアップグレードできるのでこちらを利用してもよいでしょう。

>この XPressについての質問ですが、以前にキャプチャーしたMPG-1ファイルなどの
>カット編集する場合、出力設定でフォーマット(サイズやビットレイト)を、その都度
>設定しなければならないのでしょうか？

XPRESSもPLUSも、テンプレート保存すれば、再利用できますね。

ロイさん

ありがとうございました。
早速やってみます。

PLUSでは、テンプレート保存しなくても、【MPEGツール】でカット編集する場合は
『映像ソース』のフォーマットがそのまま適用されていたように思うのですが、
間違いでしょうか？

よろしくお願い致します。

カット編集の話でしたか、エンコードの話だと思いこんでいました。

PLUSのMPEGツールの結合（カット）では、エンコードはしないので、
入力ソースと同じフォーマットで出力されますね。
また、カットできる単位はGOP単位(15〜18フレーム程度毎)です。

ただし、MPEGツールの結合（カット）で、保証される入力ソースは、
TMPGEncで作成されたCBR(固定ビットレート)のMPEGファイルとなっています。
まあ、CBRのMPEGファイルならばTMPEGENC以外で作成したものでも大丈夫だと思いますが。
ただし、VBR(可変ビットレート)のMPEGファイルだと、音声のカット位置がずれて、
正しくカットできなかったと思います。

XPRESSでは、上記のような不完全なカット編集の機能は搭載できないとのことなので、
MPEGツールから結合（カット）の機能が削除されています。

その代わり、別製品としてフレーム単位でカット編集ができるTMPGEnc MPEG Editorが発売されました。

おしまい

ロイさん

詳しい説明をしていただき、大変ありがとうございました。
カット編集の部分が、ようやく少しずつ分かってきました。

必要におおじて、XPRESとPLUSを使い分けていきたいと思います。
ありがとうございました。

TMPGEnc2.5のフリー版(Ver.2.521.58.169)を使っています。今までこんな事が無かったんですが、44％位の所で「スキャンディスクのラインインデックスを超えました」とエラーメッセージが出て変換が止まいました。それから何度やっても同じ所で止まってしまいます。自分なりに調べたんですがコーディックに関して経験が浅くてよく分りません。申し訳ないですがどなたかメッセージの意味と対処方法を教えていただけないでしょうか。よろしくお願いします。

とりあえず、環境設定→CPUでマルチスレッド関係のオプションをすべて外してみると
どうでしょう？　それで直らなければ、変換元のソースファイルに問題がある可能性が
高いので、どうにもならないかも。

DiviX5.1のファイルをMPEG1にしようとしたんですが、フィールドオーダー判定中となって９％の所でとまってしまいます。TMPGだけフリーズするんですが何か原因があるんでしょうか？？

9％付近で映像が壊れている可能性が有ります。
通常はとまることはありません。

いま、ふと思ったんですが。
WindowsのメディアプレーヤーでそのDivXファイルを再生する時、右下にDivXのロゴが見えませんか？
見えるなら見えないようにDivXの設定を変えて見てください。

初歩的な質問ですみません。
ビデオカメラで録画し、パソコン編集し、チームメイトの紹介ＤＶＤみたいなのを作成したいのです。
（例えば市販されているスノーボードＤＶＤやサッカーＤＶＤみたいに）

そこで質問なのですが、フレームとフレームの切り替わり部分の編集（画像のフェードイン、フェードアウト等の）は可能なのでしょうか？

また、ＢＧＭをかぶせる事は可能なのでしょうか？
可能な場合、それはどういう単位で設定できるのですか？
例えば、フレーム単位とかチャプター単位とか全くフリーなのか。

TMPGEnc MPEG Editor及びTMPGEnc DVD Authorを使えば、市販されているＤＶＤみたいに作成できますか？

TMPGEnc MPEG Editor及びTMPGEnc DVD Authorだけでは、現状では出来ません。

>そこで質問なのですが、フレームとフレームの切り替わり部分の編集（画像のフェードイン、フェードアウト等の）は可能なのでしょうか？

TMEは高速なカット編集に特化されたソフトです。
なので、トランジョンはできません。

>また、ＢＧＭをかぶせる事は可能なのでしょうか？

これもTMEの仕事じゃないです。

>可能な場合、それはどういう単位で設定できるのですか？
>例えば、フレーム単位とかチャプター単位とか全くフリーなのか。

編集ポイントはフレーム単位です。

>TMPGEnc MPEG Editor及びTMPGEnc DVD Authorを使えば、市販されているＤＶＤみたいに作成できますか？

まずはビデオ編集ソフトを購入しましょう。
安価なところではULEAD DVD Movie Writer 3あたり。
本格的にトランジョンを入れるならAdobe Premireですね。PremireもElementsという入門版が出ているので検討してみましょう。

DVDオーサリングで高度なメニューを求めるなら（TDA以上の機能）、プロ用になるので高価になってしまいます。（マルチアングルとか、マルチチャンネル音声とか）

これ以上はPEGASYS製品とかけ離れてしまうので、この辺でやめておきます。

Ｂｉｔｃａｓｔ　ＴＶから録画したＭＰＥＧ2ＦＩＬＥを映像と音声を分離してオーサリングソフト（ＤＶＤＡＵＴＨＯＲＧＵＩ）でＤＶＤに焼くと音がずれてしまいます。（音が0.5〜1秒先行）どうしたらよいのでしょうか？

TMPGEncを使用しているようには見えないのですが・・

bitcast.TV
http://bitcast.tv/

DVDAuthorGUI
http://www.videohelp.com/~liquid217/dvdauthorgui.pl?p=news

こちらのサポート＆BBSをお使いになられた方が良いと思います。


また、TMPGEncは試用することができます。
http://www.pegasys-inc.com/ja/download/index.html
ここからDLして試してみると良いかも。

SONY PSXにて録画した番組をDVD-RWに焼いてPCにてMPEG2にして保管したいのですが、MPEG2変換したファイルの画質がどうも良くないです。
ジャギーというのでしょうか？。まっすぐのはずの線がギザギザになったりします。

手順は、
PSXにてSPモードで録画。(試しましたがHQモードでも同じ)
DVD-RWへビデオモードで吐き出し。
PCにてスマートリッパーで吸い出し。
DVD2AVIにてプロジェクトファイルの作成(で良いのでしょうか？)

TMPGEnc2.5にて以下、
プロジェクトウィザード使用
「DVD-NTSC」選択
映像ファイルと音声ファイルを選択
そのままエンコード

という手順で処理しています。

もしかしてそもそもmpeg2にエンコードする時点で画質の大幅劣化はさけられないのでしょうか？

よろしくお願いします。

PSXで録画した時点でMPEG2なはずです。

>手順は、
1.>PSXにてSPモードで録画。(試しましたがHQモードでも同じ)
2.>DVD-RWへビデオモードで吐き出し。
3.>PCにてスマートリッパーで吸い出し。
4.>DVD2AVIにてプロジェクトファイルの作成(で良いのでしょうか？)
3.の作業は不要かと。
(エクスプローラで単純にコピーできるはず)
4.の作業で設定ミスをしていると思われます。
(フィールドオーダーを間違えている)

代替案として、MPEG-2 VIDEO VFAPI Plug-Inを使う方法があります。
http://www.marumo.ne.jp/mpeg2/
こちらを使用して、フィールドオーダーを間違えなければ、
ジャギ(インターレース解除ミス？)を回避することができると思います。

また、TMPGEnc XP3.0なら、直接DVD-RWから読み取れると思います。
こちらも試用してみては如何でしょう？

>もしかしてそもそもmpeg2にエンコードする時点で画質の大幅劣化はさけられないのでしょうか？
『非可逆圧縮』がどういう物かを調べると良いと思います。
(元の画質よりよくなることはありません)

ただ単にレコーダーで録画したものをMPEG-2ファイルにしたいだけなら、そんな面倒で
時間が掛かり無駄に画質を低下させる方法ではなく、TMPGEnc MPEG Editorを使えば
良いように思います。

DVD-RWから直接読み込めますし、エンコードしませんから画質の低下も最低限(カット
編集した部分のみ)で済みます。ただしDVDレコーダーのディスクを扱うならAC-3プラグ
インも必要ですが。

DVD2AVIのフィールドオーダーの設定を変える事で無事エンコード出来ました。

「DVD-VIDEO(HDDレコで録画したものをDVD-RWに焼いた物)からMPEG2ファイルを作りたい」
時には「TMPGEnc MPEG Edigtor」を使えば良いと言う事ですが、この作業に加え、MPEG2ファイルからDVD-VIDEOに戻す際はおそらく「TMPGEnc DVD Author 1.6」を使えば良いんじゃないかと考えているのですが、このソフトで上記作業も出来るのでしょうか？

どうも素人には各製品の特徴がよくわからないのですが、
TMPGEncの製品が、
「TMPGEnc DVD Author 1.6」
「TMPGEnc MPEG Edigtor」
「TMPGEnc 3.0 XPress」
とあるのですが、基本的にこの3つのソフトは上位互換性があると考えて良いのでしょうか？

自己レスです。

ソニスタのクーポンの期限が迫っていたので、「TMPGEnc DVD Author 1.6」「TMPGEnc MPEG Edigtor」「AC3何とか〜」のセットを購入しました。

とりあえず当初の目的を達成出来ました。
ありがとうございました。

あとの質問は該当する板に書き込みします。

No.50126, 1799 の質問、要望とかぶるのですが、
TMPGEnc Plus 2.5の「YUVデータをCCIR601ではなく、Basic YCbCrで出力する」の
機能を要望します。

自分の使い方としては、
1. MTV1000でMPEGキャプチャ
2. aviutlで編集し、プロジェクト保存。
3. TMPGEncでMPEG再圧縮
のような使い方が多いのですが、基本的にキャプチャしたときのままの
色で出力したいと思っています。

2でPCスケールに変換すればよいとは思うのですが、なるべくなら無駄な変換は
したくありません。

以上、よろしくお願いします。

VFAPIで誤解があるかもしれまん。

AviutlからTMPGEncへVFAPIを経由してデータを渡す場合
Aviutlに投入の時点でMPEGの16〜235をPCスケール（0〜255）にしていると
0〜15、236〜255にMPEG時に存在していたデータはRGB化（VFAPI経由時）で消えます。
ですので、
>2でPCスケールに変換すればよいとは思うのですが、
これは行わないのが正解だと思います。

「3」でTMPGEncの色補正でいい感じに設定してエンコードするのが現在の一番いい手
となりますね。

あとは、全部の作業をTMPGEnc 3.0でするか　かな。

TMPGEnc 3.0は入力をYUVにさえすればRGB仕様のフィルタを通過しなければ
YUV0〜255はMPEG圧縮後も0〜255有るんで、VFAPIとか非圧縮AVIなどを使わない方向を
考えるのも良いかもしれません。

＞ちょうきさん

http://www3.tcn.ne.jp/~rakka/temp/src.png
ソースのMPGファイルのヒストグラム

http://www3.tcn.ne.jp/~rakka/temp/2.5.png
TMPGEnc Plus 2.5で「YUVデータをCCIR601ではなく、Basic YCbCrで出力する」を
ONにして出力したMPGファイルのヒストグラム

http://www3.tcn.ne.jp/~rakka/temp/3.0.png
TMPGEnc 3.0 XPressで出力したMPGファイルのヒストグラム

上の結果からTMPGEnc 3.0では、PC->TVスケール補正が行われているものと
判断しました。

自分としては、色合いについて主観で良いか悪いか判断できないので、
なるべくソースと同じヒストグラムになるように出力したいと思っています。

ですので、aviutlでTV->PCスケール補正をかければ、情報量は減りますが
まだましなものができるのでは？と思いました。
TMPGEncでも色補正できますが、TMPGEncでTV->PCスケール補正と
同等の補正を行うのは手間がかかりすぎるように思いますし、
また、TV->PCスケール補正後と同様のヒストグラムになるように
補正をかければ、結局、情報量は同じだけなくなるように思うのですが
どうでしょうか？

この辺は難しいのですが
MPEG圧縮は基本的にRGB0〜255をYUV16〜235として圧縮し、再生時に0〜255として再生するのが基本です。
（ですので、まるもデコーダーとかにはストレート変換（16〜235のまま）やCCIR601伸張（規定の伸張作業）の2個が有ったりします。）
再利用用のCRIデコーダーやまるもデコーダーなどは別として、最終的な再生側はDVDプレーヤー
であったり、DVD-MPEG再生ソフトであったりします。
この場合CCIR601伸張が基本となります。（CCIR601伸張された絵が正解）
つまりMPEGではCCIRの圧縮・伸張は1セットと言う事です。

この再利用時の伸張作業なのですが、Aviutlに読み込ませる前のデコーダーで行う場合、Aviutlで行う場合、
TMPGEnc 3.0 XPress(以下3.0)で行う場合の3つが考えられます。

私はこの3つ目の3.0に来てから、色調補正内の「YUVのCCIR伸張」で輝度・色差を両方とも255にするという
作業でCCIR伸張（つまりPCスケール変換）を行うのが良いのではないかなと思うわけです。

いずれにせよ「YUVデータをCCIR601ではなく、Basic YCbCrで出力する」が無い現状では
上記作業でRGBソースをYUVにすると0〜15、236〜255に存在していたソースは無くなります。
でも精度的にVFAPIを一度介すよりも3.0内で行った方がいいのでは無いかと思うわけです。

まぁ今回のケースで一番いいのは、VFAPIを介さず、HuffyuvなどでAviutlから一度出力して
それを3.0に読み込ませればYUVソースとして扱われるのでデータは全部残るんでは無いかな
と思います。（VFAPI経由は重いので実質のエンコード時間はhuffyuv出力時間を入れても減るかも）

>私はこの3つ目の3.0に来てから、色調補正内の「YUVのCCIR伸張」で輝度・色差を両方とも255にするという
>作業でCCIR伸張（つまりPCスケール変換）を行うのが良いのではないかなと思うわけです。

実際に試したところ、aviutlでTV->PCスケール補正をかけたのと同じヒストグラムに
なりました。TMPGEnc 3.0の色調補正で簡単に同様のことができるとは
知りませんでした。

>まぁ今回のケースで一番いいのは、VFAPIを介さず、HuffyuvなどでAviutlから一度出力して
>それを3.0に読み込ませればYUVソースとして扱われるのでデータは全部残るんでは無いかな
>と思います。（VFAPI経由は重いので実質のエンコード時間はhuffyuv出力時間を入れても減るかも）

なるほど。huffyuv形式のaviファイルは色情報をYUV形式で持っているので
TMPGEncはMPGファイルと同様にCCIR圧縮を行わないのでは？ということですね。
多少、作業が増えますが、できれば自分の期待する形で出力できますね。

いろいろと役に立つ情報、ありがとうございました。

ただ、やはりTMPGEncとしては、VFAPIから入力されたデータがMPGファイルで
あることも考慮して、CCIR圧縮を行わないという設定をできるように
して欲しいと思っています。

Huffyuv v2.1.1をインストールし、設定は特に変更せずに
Huffyuv形式でavi出力し、TMPGEncに入力し、DVD NTSC形式で出力したのですが
CIIR圧縮されていました。

とりあえず今のところは、TMPGEncでCCIR伸張するしかないのかもしれません。

間違っていました。
HuffyuvもYUVなので、Hufyuv化時にRGB＞YUV変換が入ります。（16〜235になる）
これを回避するには・・・・

Basic YCbCrで保存　に相当する機能の有る HuffyuvS を使うとか・・・（0〜255のYUVで保存するHuffyuvの派生）
うーんややこしくなってきました(^^;

>Basic YCbCrで保存　に相当する機能の有る HuffyuvS を使うとか・・・（0〜255のYUVで保存するHuffyuvの派生）

HuffyuvSで検索してみたところ、

huffyuvs 0.6 left origin base2.1.1
huffyuvs 0.6 left origin base2.1.1 ccesp

の2つが見つかったのですが、どちらを使えばよいのかわかりませんでした。
名前からするとccespはCCE-SP用に出力する場合？のように思われるのですが
ネットで見つかったページを見ているとccespでよいようにも思います。

ccespでよいのでしょうか？

ごめんなさい、寝ぼけてました。

Aviutlの98d辺りのバージョン以降を使っておられるなら、まるもさんのデコーダー
m2v.vfpをm2v.auiとリネームしてAviutlのフォルダへ置くことでYUV読み込みが可能になります。
これで元のYUVデータを維持してYUV読みこみ出来ているので、そのままHuffyuvへ出力し、
TMPGEncでもYUVで読み込む事でRGB変換を経ずに受け渡すことが出来ます。
この方法であればhuffyuvSは使わずにすみますね。

m2v_vfp-0.6.48.lzh
huffyuvs_0.6_-_left_origin_-_base2.1.1-ccesp_dll.zip
をインストールし、試してみたのですが、
出力されたMPEGファイルはCCIR601圧縮されていました。
m2v.aui、huffyuvsの設定はデフォルトのままで特に変更していません。

えっと、こんがらがらせてすみません。huffyuvSは忘れてください（^^;

以下の文では
Aviutl99およびAviutl98d、そしてまるもプラグインm2v_vfp-0.6.48とHuffyuv2.20を使用して居ます。

まず結論からですが
http://www.delmart.org/~tyouki/img/aui_non.png
上のヒストグラムのように、m2v_vfp-0.6.48のm2v.vfpを「m2v.aui」へリネームし
Aviutlのフォルダに設置し、MPEGファイルを読みこみ、それをHuffyuvで出力した物を
XPressへ読み込んだ物です。

全部YUV処理なのでCCIR圧縮は経ずにデータのやり取りが可能です。

ここで一歩踏み込んだ話を始めます。
まず
http://www.delmart.org/~tyouki/img/aui_set.png
これを見てください。
先ほどのaui_non.pngのデータをXPressで色データがどこまで残っているか　を見るために
CCIR伸張の項目でマイナス方向へセットした物です。
（再生時にはaui_non.pngの状態で見るので、このaui_set.pngの図は、より精度をのためにと考えてください。）
Aviutl98dで処理した物は乱れが出て居ます。
これはAviutl99で仕様変更となったAviutl98dのYUVの飽和の設定のせいです。
現在は精度的には99、安定性は98dと言われています。

今度はまるもデコーダーをVFAPI経由で動作（RGB処理）で動かして見ます。
http://www.delmart.org/~tyouki/img/vfp_non.png

一番最初の（http://www.delmart.org/~tyouki/img/aui_non.png）と比べても
CCIR伸張済み>Huffyuvのデータもストレート変換後Huffyuv化しXPressの色補正でCCIR伸張した物
は同じように見えます。
ストレートのものはCCIR圧縮されたままなので左右端に隙間が出来ています。

しかし、色データがどこまで残っているか調べる為にCCIR伸張の項目でマイナス方向へセットすると
http://www.delmart.org/~tyouki/img/vfp_set.png
こうなります。
デコーダでCCIR伸張後にデータを受け渡すと左右端に存在するデータが消し飛んでいます。

この結果からAviutlとXPressを使用する場合
・Aviutlプロジェクトを使う場合（またはm2v.vfpを使う場合）はストレート変換+XPressでのCCIR伸張
・Huffyuvを使う場合はm2v.vfpをm2v.auiにしてHuffyuvへYUV処理のままXPressへ

この2個が劣化が少なくてすむやり方ですね。

● 使用ソフトのバージョン
TMPGEnc 3.0 XPress Trial Version 3.1.2.66
AviUtl 0.99
Huffyuv v2.1.1
m2v_vfp-0.6.48

● 使用ソフトの設定
http://www3.tcn.ne.jp/~rakka/temp2/setting_m2v_aui.png
m2v.auiの設定

http://www3.tcn.ne.jp/~rakka/temp2/setting_Huffyuv.png
Huffyuvの設定

● CCIR伸張の項目でマイナス方向へセットした物について
http://www3.tcn.ne.jp/~rakka/temp2/src_aviutl.png
m2v.auiの設定を「ストレート変換」にし、
aviutlでsrc.m2vを読み込みんだときのヒストグラム

http://www3.tcn.ne.jp/~rakka/temp2/src_TMPGEnc.png
http://www3.tcn.ne.jp/~rakka/temp2/src_TMPGEnc(CCIR601).png
TMPGEncでsrc.m2vを読み込んだときのヒストグラムと、フィルターの
色調補正のCCIR601伸長で輝度、色差を-255にしたときのヒストグラム

http://www.delmart.org/~tyouki/img/aui_non.png
http://www.delmart.org/~tyouki/img/aui_set.png
ちょうきさんの結果の「オリジナル」のヒストグラムを見た感じでは、
aui_set.pngにおいて236〜255の値が現れていますが、
自分の結果では0になっています。
aui_set.pngは、どのようにした場合のヒストグラムになるのでしょうか？

● Huffyuv->TMPGEncについて
1. m2v.auiの設定を「ITU-R BT.601から伸張」に戻し、
aviutlでsrc.m2vを読み込み、avi(Huffyuv)ファイルを出力する。
2. avi(Huffyuv)ファイルをTMPGEncで読み込み、m2vファイルを出力する。

のようして作成されたm2vファイルのヒストグラムを見てみました。

http://www3.tcn.ne.jp/~rakka/temp2/Huffyuv_TMPGEnc.png
TMPGEncで読み込んだときのヒストグラム

http://www3.tcn.ne.jp/~rakka/temp2/Huffyuv_aviutl.png
aviutl(ストレート変換)で読み込みんだときのヒストグラム

http://www3.tcn.ne.jp/~rakka/temp2/src_TMPGEnc.png
http://www3.tcn.ne.jp/~rakka/temp2/Huffyuv_TMPGEnc.png
CCIR伸張されているTMPGEncのヒストグラムを見比べると
ソースとほぼ同じなのですが、

http://www3.tcn.ne.jp/~rakka/temp2/src_aviutl.png
http://www3.tcn.ne.jp/~rakka/temp2/Huffyuv_aviutl.png
CCIR伸張されていないaviutlのヒストグラムを見比べると、
236〜255の情報が失われているようでした。

http://www.delmart.org/~tyouki/img/aui_set.png
ちょうきさんの結果の真中の列を見た感じでは失われていないよう
なのですが、自分の処理方法、設定に問題があるのでしょうか？

>ちょうきさんの結果の「オリジナル」のヒストグラムを見た感じでは、
>aui_set.pngにおいて236〜255の値が現れていますが、
>自分の結果では0になっています。

これには裏技が有ります。
TMPGEnc 3.0 のフィルタ画面の下のオーバーレイ　をONにします。
すると、今までRGB0〜255表示だったヒストグラムが　-16〜0〜255〜275分表示可能になります。
と言っても表示されているのは0〜255の範囲なので明るさとかを下げたりCCIR逆操作を行ったりすると
ズルズルズルっと隠れていた分が出てきます。
なぜこう言う仕様なのかは知りませんが、推測するにYUV対応時の隠しモードかと。
私はG550などのグラフィックカードでTV出力時の色とかも見て色調整するのでこのモードには
気が付きました。
こっそり使ってます。

>http://www3.tcn.ne.jp/~rakka/temp2/src_TMPGEnc(CCIR601).png
こちらのヒストグラムの状態でオーバーレイをON,OFFすれば右の絶壁がなだらかになると思います。

aui読みこみの際はYUVで読み込むのでCCIR伸張は全く不要です。
YUV0〜255がYUV0〜255で扱われます。これをAviutlでHuffyuvで出す時はファイル＞環境設定＞コーデックの設定で
HuffyuvがYUY2で圧縮　にチェックが入っている事を確認して置いてください。
これをTMPGEncで読み込んでください。
ヒストグラムでのチェックはTMPGEncでもう一回ためして見てください。

>これには裏技が有ります。
>TMPGEnc 3.0 のフィルタ画面の下のオーバーレイ　をONにします。
>すると、今までRGB0〜255表示だったヒストグラムが　-16〜0〜255〜275分表示可能になります。
>と言っても表示されているのは0〜255の範囲なので明るさとかを下げたりCCIR逆操作を行ったりすると
>ズルズルズルっと隠れていた分が出てきます。

オーバーレイをONにしたところ、CCIR圧縮したときに236〜255の値が
表示されるようになりました。

>aui読みこみの際はYUVで読み込むのでCCIR伸張は全く不要です。
>YUV0〜255がYUV0〜255で扱われます。これをAviutlでHuffyuvで出す時はファイル＞環境設定＞コーデックの設定で
>HuffyuvがYUY2で圧縮　にチェックが入っている事を確認して置いてください。
>これをTMPGEncで読み込んでください。
>ヒストグラムでのチェックはTMPGEncでもう一回ためして見てください。

http://www3.tcn.ne.jp/~rakka/temp3/setting_aviutl_codec.png
aviutlのコーデックの設定です。

http://www3.tcn.ne.jp/~rakka/temp2/src_TMPGEnc.png
ソースのm2vファイルをTMPGEncで読み込んだときのヒストグラム

http://www3.tcn.ne.jp/~rakka/temp3/Huffyuv_avi_TMPGEnc.png
aviutl(ストレート変換)でソースのm2vを読み込み、出力したaviファイルを
TMPGEncで読み込みこんだときのヒストグラム

http://www3.tcn.ne.jp/~rakka/temp3/Huffyuv_m2v_TMPGEnc.png
TMPGEncで上のaviファイルを読み込み、出力したm2vファイルを
TMPGEncで読み込んだときのヒストグラム

ソースのm2vファイルを読み込んだときのヒストグラムはCCIR伸張されているのですが
aviファイルを読み込んだときのヒストグラムはCCIR伸張されていませんでした。
そのためか最後に出力したm2vファイルのヒストグラムは、ソースのヒストグラムを
CCIR圧縮したようなヒストグラムになっていました。

http://www3.tcn.ne.jp/~rakka/temp3/setting_TMPGEnc1.png
http://www3.tcn.ne.jp/~rakka/temp3/setting_TMPGEnc2.png
TMPGEncの環境設定の入力プラグイン設定、AVIコーデック設定は
上のようになっているのですが、これの設定が関係しているのでしょうか？

http://jumper-x.hp.infoseek.co.jp/begin/column/2/
MPEG-2 VIDEO VFAPI Plug-Inの使い方

http://jumper-x.hp.infoseek.co.jp/study/6/index.html
YC伸張実験君

のページを見ていたところ、どうもAviUtlの入力プラグインの優先度の
設定が関係しているように思いました。
たぶん、MPEG-2 VIDEO Plug-InよりもMPEG-2 VIDEO File Readerの
優先度が高くないといけないと思うのですが、もしかすると
そうなっていないのかもしれません。
（現在、自宅にいないので確認できません。）

aviutlの入力プラグインの優先度の設定を見たところ、
・MPEG-2 VIDEO Plug-In
・MPEG-2 File Reader
のようになっておりm2v.vfpが使われているようでした。
MPEG-2 File Readerの優先度を上げ、上と同じようにした
結果、下のようになりました。

http://www3.tcn.ne.jp/~rakka/temp4/src_TMPGEnc2.png
src.m2vをTMPGEncで読み込みCCIR601圧縮したときのヒストグラム

http://www3.tcn.ne.jp/~rakka/temp4/src_m2v_TMPGEnc2.png
src.m2vをTMPGEncで読み込み、出力したm2vファイルを
TMPGEncで読み込みCCIR601圧縮したときのヒストグラム

http://www3.tcn.ne.jp/~rakka/temp4/Huffyuv_m2v_TMPGEnc2.png
src.m2vをaviutlで読み込み、出力したavi(Huffyuv)ファイルを
TMPGEncで読み込み、出力したm2vファイルを
TMPGEncで読み込みCCIR601圧縮したときのヒストグラム

ヒストグラムはほぼ同じなので、Huffyuvを中間ファイルとして
出力すれば、とりあえずTMPGEnc Plus 2.5の
「YUVデータをCCIR601ではなく、Basic YCbCrで出力する」で
出力したのと同じような結果が得られることがわかりました。

ただ、Huffyuvを中間ファイルとして出力するためには空き容量が
結構いるので、Huffyuvを中間ファイルとして使わない方法についても
試したいと思います。（試用期間が残り少ないので厳しいですが）

>この結果からAviutlとXPressを使用する場合
>・Aviutlプロジェクトを使う場合（またはm2v.vfpを使う場合）はストレート変換+XPressでのCCIR伸張
>・Huffyuvを使う場合はm2v.vfpをm2v.auiにしてHuffyuvへYUV処理のままXPressへ

の上の方法について。

1. aviutlの入力プラグインの優先度の設定において、MPEG-2 VIDEO Plug-In(m2v.vfp)の
優先度をMPEG-2 File Reader(m2v.aui)よりも上にする。
2. m2v.vfpの設定を「ストレート変換」にする。
3. src.m2vをaviutlで読み込み、プロジェクトファイルを出力する。
→ src.aup
4. src.aupをTMPGEncで読み込み、CCIR601伸張し、m2vファイルを出力する。
→ src_aup.m2v

のようにしたときのヒストグラムは以下のようになりました。

http://www3.tcn.ne.jp/~rakka/temp5/src_TMPGEnc2.png
src.m2vをTMPGEncで読み込み、CCIR601圧縮したときのヒストグラム

http://www3.tcn.ne.jp/~rakka/temp5/src_aup_TMPGEnc.png
http://www3.tcn.ne.jp/~rakka/temp5/src_aup_TMPGEnc2.png
src.aupをTMPGEncで読み込んだときのヒストグラムと
CCIR601伸張したときのヒストグラム

http://www3.tcn.ne.jp/~rakka/temp5/src_aup_m2v_TMPGEnc2.png
src_aup.m2vをTMPGEncで読み込み、CCIR601圧縮したときのヒストグラム

最後のヒストグラムとソースのヒストグラムを見比べた感じでは、
235〜のデータがなくなっているように思います。

>・Aviutlプロジェクトを使う場合（またはm2v.vfpを使う場合）はストレート変換+XPressでのCCIR伸張
の方法は、上の1〜4の操作とは異なるのでしょうか？

>>・Aviutlプロジェクトを使う場合（またはm2v.vfpを使う場合）はストレート変換+XPressでのCCIR伸張
>の方法は、上の1〜4の操作とは異なるのでしょうか？

これは、aupを読んでるという事はTMPGEnc3.0がRGBモードなので
ヒストグラムで０〜２５５に見えている範囲が全てと言う事になりますね。
ですんでTMPGEnc3.0をYUVモードで動かす事が肝要ってことだと思います（Huffyuv経由）

>この結果からAviutlとXPressを使用する場合
>・Aviutlプロジェクトを使う場合（またはm2v.vfpを使う場合）はストレート変換+XPressでのCCIR伸張
>・Huffyuvを使う場合はm2v.vfpをm2v.auiにしてHuffyuvへYUV処理のままXPressへ
>
>この2個が劣化が少なくてすむやり方ですね。

のように書かれている2つの方法の上の方法については、
Huffyuvを経由する方法ではないように思ったのですが違うのでしょうか？

一応、aup入力だとRGB入力になって、Huffyuv入力だとYUV入力になることは
これまでの議論？で理解しています。
結局のところ、全く損失なくMPEG出力する場合、
Huffyuv入力するしかなく、aup入力する場合は235〜の損失は避けられない、
ということでよろしいでしょうか？

>Huffyuv入力するしかなく、aup入力する場合は235〜の損失は避けられない、
そう言うことだと思います。
二転三転してすみません（^^;